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Abstract —Clock synchronization is highly desirahle in dis- 
trihuted systems, including many applications in the Internet 
of Things and Humans (loTH). It improves the efficiency, 
modularity and scalability of the system; and optimizes use 
of event triggers. For loTH, Bluetooth Low Energy (BLE) - 
a subset of the recent Bluetooth v4.0 stack - provides a low- 
power and loosely coupled mechanism for sensor data collection 
with ubiquitous units (e.g., smartphones and tablets) carried 
by humans. This fundamental design paradigm of BLE is 
enabled by a range of broadcast advertising modes. While its 
operational benefits are numerous, the lack of a common time 
reference in the broadcast mode of BLE has been a fundamental 
limitation. This paper presents and describes CheepSync: a 
time synchronization service for BLE advertisers, especially 
tailored for applications requiring high time precision on resource 
constrained BLE platforms. Designed on top of the existing 
Bluetooth v4.0 standard, the CheepSync framework utilizes low- 
level timestamping and comprehensive error compensation mech¬ 
anisms for overcoming uncertainties in message transmission, 
clock drift and other system specific constraints. CheepSync was 
implemented on custom designed nRE24C/iee/; beacon platforms 
(as broadcasters) and commercial off-the-shelf Android ported 
smartphones (as passive listeners). We demonstrate the efficacy 
of CheepSync by numerous empirical evaluations in a variety of 
experimental setups; and show that its average (single-hop) time 
synchronization accuracy is in the 10 ps range. 

I. Introduction 

A common time reference is an important requirement 
for distributed systems. The accurate knowledge of time is 
primeval for concurrency control, data consistency/ordering, 
security, communication protocol management, etc., in 
wireless networks, network control and sensor networks; 
without which the system performance. Quality of Service 
(QoS), and safety would get severely affected. Time 
synchronization across distributed clocks is an area with a 
rich history.lt includes a whole gamut of solutions covering 
the notion of ordering of events with virtual clocks ||T| to 
relative/absolute synchronization Q-ID for platforms that 
are resource savvy to constrained. In this regard, developing 
a common time service for distributed systems consisting of 
constrained devices is particularly challenging. 

In the recent past, a new class of constrained platforms 
based on Bluetooth Low Energy (BLE) 0 have emerged. 
BLE is different from other wireless technologies because 
it combines a standardized communication technology 
designed for low-power systems, and a new sensor-based 
data collection framework. It also offers easy integration 
with most handheld devices (such as smartphones and 


tablets), something that traditional wireless sensor networks 
(WSN) are still working towards. BLE has inherited several 
technical features from Classic Bluetooth that provide for 
robust, reliable connections. However, the most significant 
difference is its asymmetric design. While the standard 
mode of operation is typically based on a master device 
connected to a number of slave devices, it offers a new 
feature in the form of an ‘advertisement’ (configurable 
through the broadcast/peripheral mode of BLE). This new 
mode offers unidirectional communication between two or 
more LE devices using advertising events, thereby achieving 
a communication solution without entering into a bonded 
connection (as required by Classic Bluetooth devices). Such 
a loose coupled manner of data transfer is undoubtedly more 
energy efficient; but also unearths other limitations. Eor 
example, the broadcast mode of communication does not 
provision for a time synchronization service; even though 
this feature is included in the solution stack, but can only be 
availed upon pairing. 

Challenges. BLE provides a range of broadcast 
advertising modes, of which the most energy efficient 
is the non-connectable undirected advertising mode 
(ADV_N0NC0NN_IND); a transmit-only, broadcaster mode 
without any listen window. Establishing time synchronization 
in this mode of BLE operation is challenging due to many 
reasons. First, the traditional techniques of message passing 
among different elements is not supported by this network 
architecture (i.e., Bluetooth v4.0 specific); and as a result, 
timing uncertainties cannot be compensated by exchanging 
time stamped packets, or ‘pings’ between nodes. Second, 
devices receiving advertisement data (such as smartphones) 
have high functional asymmetry compared to the BLE 
broadcast units. They typically run on a multithreaded and 
multitasking operating systems (OS) (such as Android) 
where the measure of system latencies and their associated 
uncertainties can be many orders of magnitude higher than 
those at the transmitter end. Third, low-level timestamping 
on such multifunctional receiver devices can be performed 
to a certain limit and is subject to system restrictions of the 
underlying firmware. Therefore, motivated by the need to 
overcome the above limitations and yet be able to establish 
a common time reference across resourced constrained BLE 
devices operating in the ADV_N0NC0NN_IND mode, we 
propose CheepSync. 
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Contributions and Road-map. Due to the architectural 
constraints, the key ideas of CheepSync are; (1) not to 
synchronize the nodes in the network, but to make the 
devices that use these nodes synchronize; and (2) piggyback 
on the device mobility aspect (as they are inevitably carried 
by people) and use them as ‘synchronization mules’ for 
the ‘broadcast’ system. Thus, it offers a flexible piggyback 
design wherein running the time service does not require data 
transactions to be temporarily suspended. Therefore, time 
synchronization with CheepSync is highly implicit rather 
than explicit. Since CheepSync rides on the BLE broadcast 
framework, it is scalable to the point that the framework has 
to offer. 

In this article, we provide a synopsis of the BLE broadcast 
mode and Bluedroid (the default Android Bluetooth stack) 
along with system details of building a BLE fakery platform 
in the next section. It is followed by a detailed design and 
analysis of the CheepSync architecture and performance 
that is able to achieve an average time synchronization 
accuracy in the range of 10/rs. The hnal sections provide a 
concise background of existing work in this related held, and 
concludes with a summary of the areas covered in the article. 

II. System Overview 

The system is composed of two units: beacon and control. 
The beacon unit consists of resource constrained sensing tags 
that are deployed in the region of interest. They are responsible 
for measurement of simple physical parameters, and dissemi¬ 
nating that information through undirected BLE broadcasts. 
The control unit consists of a resourceful gateway device 
capable of listening and receiving broadcast data contained 
in BLE advertisements. Eor our application requirements, the 
beacon unit is a custom designed nRE24C/ieep BLE platform, 
and the control unit is an Android v4.4.4 smartphone that uses 
Bluedroid (the default Android Bluetooth stack). 

To ground our discussion, we hrst provide an overview of 
BLE in this section, followed by a detailed explanation of the 
nK¥2ACheep platform and the Android Bluedroid stack. 

A. BLE Synopsis 

BLE is a subset of the Bluetooth v4.0 stack, and is designed 
for low-power applications interested in knowing the state 
of the physical world. It is, therefore, not suitable for high 
data rate applications, which are better served by the existing 
Bluetooth 2.0 EDR or Bluetooth 3.0 HS protocols. BLE 
enabled systems are inherently asymmetric in-nature with large 
numbers of simple, resource constrained peripherals devices 
(that interact with the physical space); and few complex, 
resource savvy central devices (that act as gateways to the 
cyber space). 

BLE operates in the unlicensed 2.4GHz ISM band. It 
dehnes 40 channels (numbered 0-39), each separated by 
2 MHz. Three of these channels (37, 38, 39) are reserved 
for advertising and are used for device discovery, connection 
establishment and broadcast (one-way) communication; while 
the remaining channels are dedicated for bi-directional com¬ 
munication between connected devices. BLE ensures reliable 
coexistence with other competing RE technologies (especially 


WiEi) operating in the ISM band by using non-overlapping 
frequencies for the three advertisement channels, while it 
adopts an adaptive frequency hopping mechanism for the data 
channels. 

In the broadcast mode of communication, as part of an 
advertisement event, the advertiser (i.e., the peripheral device) 
sequentially transmits an advertisement packet on each ad¬ 
vertisement channel within a specihed time period. Broadcast 
packet transmissions are kept short with only 31 bytes avail¬ 
able for application payload, in addition to other necessary 
helds such as the preamble, header. Medium Access Control 
(MAC) address and checksum. Such packets are received 
by any central device that is passively listening to such 
broadcasts. Eor bidirectional and unconstrained data transfer, 
the respective devices need to be paired and connected. The 
data exchange in this mode is enabled by the Generic Access 
Prohle (GAP), a light-weight client-server mechanism that also 
supports predehned or user dehned Generic Attribute (GATT) 
services. 

BLE dehnes four type of broadcast mechanisms: (1) 
connectable undirected advertising ADV_IND, (2) con¬ 
nectable directed advertising ADV_DIRECT_IND, (3) non- 
connectable undirected advertising ADV_NONCONN_IND, and 
(4) scannable undirected advertising ADV_SCAN_IND. Of 
these, ADV_NONCONN_IND is the singular transmit-only 
broadcast mode without any scope for listening back. Thus, 
it facilities BLE-enabled platforms to much more constrained 
in terms of energy and communication capabilities than the 
current state-of-the-art. 

In the following subsection, we describe our experiences in 
building a custom BLE beacon platform that uses BLE fakery 
over a general purpose radio, a tool for conducting research 
in this direction. 

B. nRF24Cheep BLE Beacon Platform 

The custom designed beacon platform, nRF2ACheep, con¬ 
sists of a: RL78-G14 CD microcontroller, nRE24L0lH- d 
2.4GHz RE transceiver with an embedded baseband proto¬ 
col engine (Enhanced ShockBurst^”), TPS62730 synchronous 
step-down DC-DC converter, and CR2032 battery holder. The 
microcontroller has a RL78 core with 16-512 KB hash mem¬ 
ory, and operates at a maximum clock speed of 64 MHz with 
a high precision (±1%) on-chip oscillator. It also provides a 
range of interval timers for different application requirements. 
The nRE24L0lH-, although not strictly compatible with BLE, 
can be made to operate as a BLE transmitter by conhguring 
the transceiver setting^ This allows BLE listeners/scanners to 
view the nRE24L0lH- as a BLE device and decode its adver¬ 
tisement data. The nRE24L0lH- interfaces with the application 
controller (RL78-G14) over a high speed Serial Peripheral 
Interface (SPI) bus. Enhanced ShockBurst’^”, designed to 
handle all the high speed link layer operations, is based on 
packet communication and supports 1 to 32 bytes of dynamic 
payload length. Data how between the radio front end and the 
microcontroller is through internal EIEOs. 

*The necessary RF configurations for BLE compliance can be obtained 
from |14|. 
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(a) Platform overview 



(b) Functional representation of the major platform components 


Fig. 1: nRF24C/iee/;: custom designed BLE Beacon platform. The major components include: RL78-G14 microcon¬ 
troller, NRF24L01+ mi 2.4 GHz RF transceiver, TPS62730 synchronous step-down DC-DC converter, and CR2032 battery 
holder. 


nRr24L01 Hardware Interface: The nRF24L01 module has 
the following eight interfacing pins, of which four are SPl 
related: CSN, SCK, MISO, MOSI; and the remaining ones 
are: Vcc, GND, IRQ, CE. 

The SPI interface is used for data transmission and recep¬ 
tion between the radio (slave) and the microcontroller (master). 
The active-low CSN (chip select not) is the enabler pin for the 
SPl bus, while the SCK pin is its serial clock. CSN is nor¬ 
mally kept high except when there is command/data exchange 
between radio and the microcontroller. MOSI (or Master Out, 
Slave In) is the pin on which the master communicates with 
the slave, and vice versa for the MISO (or Master In, Slave 
Out) pin. 

CE is used to control data transmission and reception in TX 
and RX modes, respectively. In TX mode, CE is always held 
low except when the packet has to be transmitted; and is done 
by loading the TX EIEO and then toggling the CE pin. IRQ 
is the interrupt pin, and can be used to assert three internal 
interrupts, viz.', data received, data transmitted, and maximum 
number of transmit retries reached. 


C. Android BlueDroid Stack 

BlueDroid is the default Bluetooth stack of Android, and 
consists of two layers. The Bluetooth Embedded System 
(BTE) layer holds the core Bluetooth functionality, while 
communication with Android framework is handled by the 
Bluetooth Application Layer (BTA). A Bluetooth system ser¬ 
vice communicates with the Bluetooth stack through Java 
Native Interface (JNI) and with applications through Binder 
Inter-process Communication (IPC). The android applica¬ 
tion code (at the framework level) utilizes the APIs of 
android.bluetooth to interact with the bluetooth hard¬ 
ware that internally, through the Binder IPC mechanism, 
calls the Bluetooth process (both the Bluetooth service and 
prohles). The packaged android app uses JNI to call into the 
hardware abstraction layer (HAL) and also receive callbacks. 


Located in: external/bluetooth/bluedroid, the de¬ 
fault Bluetooth stack implements the generic Bluetooth HAL 
as well as customizes it with extensions and configuration 
changes. 


HI. CheepSync: 

Time Synchronization Protocol 


The basic CheepSync mechanism uses the broadcaster mode 
of BLE to transmit a single advertisement packet from the 
beacon (transmitter) unit to the control (receiver) unit. The 
broadcasted message contains: (i) the transmitter’s current 
timestamp value, which is a counter held that increments 
every interval ms, and is the estimated local time at the 
transmission of the advertisement packet; and (ii) the aggregate 
delay incurred during the transmission of the previous packet. 
On message reception, the receiver obtains the corresponding 
‘wall’ clock time expressing time (in nanoseconds) since the 
epoch. In principle, two broadcast packets provide a syn¬ 
chronization point between the transmitter and the receive]]^ 
The difference between the local and ‘wall’ clock time of 
a synchronization point estimates the clock offset of the 
transmitter. 

The counter value ts_counter is needed to estimate the time 
elapsed on the beacon unit. If the underlying platform uses 
a 6 bit held to store the timestamp value and the timer hres 
every interval ms, then the total time that can be represented 
by the timestamp held is (2^ * interval) ms. Therefore, the 
conhguration of 6 = 24 bits and interval = 100 ms can be 
used to make the timestamp value work for approximately 
19 days without rolling oveij^ 


^In Section 


III-A 


we explain how the determinism of time delays on the 


nRF24Cheep beacon platform benefits our implementation. Therefore, for our 
platform of choice, only a single broadcast packet (instead of two) is apt for 
reliably synchronizing the transmitter and the receiver. 

^Our system design is based on the assumption that there must be a 
control unit that passes by the beacon units, atleast once over a 19 day 
period. However, under overriding circumstances, the system can determine 
the number of counter rollovers. 
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In the next subsection, we discuss the general uncertainties 
associated with RF message delivery and then converge to our 
specihc use case. It is then followed by a detailed explanation 
of the structure of the BLE advertisement packet with specihcs 
into the packet restructuring as per the nRF24L01+ Enhanced 
ShockBurst’^” protocol engine. 


A. Sources of Time Synchronization Error 

Time synchronization is affected by nondeterministic delays 
(that are many orders of magnitude greater than the required 
time accuracy), often arising from random events during the 
process of radio message delivery. We shall use the following 
error decomposition model ||2|-Q, Q, p3| to better under¬ 
stand the sources of latency; and modify it according to the 
specihcs of the platform and radio-of-interest. 

• Send Time. It is the time spent by the transmitter to 
assemble the message and trigger the send request to the MAC 
layer. It is, therefore, a function of the processor load and 
the system call overhead of the respective OS ported on the 
transmitter platform. nRF24C/!eep does not have an OS port, 
and makes direct system calls to the underlying hardware 
without any (potential) soft routing. This enables more user 
control over different system modules (albeit, increased com¬ 
plexity), and therefore, helps to reduce delays that are typically 
nondeterministic and were previously difficult to calibrate. 

• Access Time. It is the delay incurred waiting for access to 
the transmit channel up to the point when transmission begins, 
and is specihc to the MAC protocol in use. It is considered the 
least deterministic part of the message delivery system. BLE 
does provision for a (TDMA/FDMA) MAC, but it is only 
operational in connection mode. Access control rules have not 
been dehned for the BLE broadcast mode of communication; 
and so, packets get pushed on to the physical channel as and 
when they are bagged for transmission. 

• Transmission Time. A function of the length of the message 
and the radio speed, it is the time taken by the transmitter to 
transmit the message and is a deterministic component. 

• Propagation Time. Once the message has left the transmit¬ 
ter, it is the time needed to transit to the receiver. For many 
application requirements (wherein the channel length is under 
300 m), this delay is highly deterministic and less than 1 fj,s. 

• Reception Time. It is the time taken by the receiver to 
receive the message. In our case, it is the most nondetermin¬ 
istic part of the message delivery mechanism as the receivers 
are Android ported smartphones that run multiple tasks and 
process threads at the same time. Therefore, depending on the 
system state, a BLE packet can take several milliseconds to 
propagate to the application layer. 

• Receive Time. It is the time required to process and notify 
the incoming message to the receiver application. 

We perform low-level timestamping, both at the transmitter 
and receiver end, to overcome the above-stated uncertainties in 
a message transaction; the details of which are discussed sub¬ 
sequent to the BLE advertisement packet format that follows 
next. 


B. Advertisement Packet Format 

There is a single format for a BLE (advertisement or data) 
Packet, and it consists of the following/owr helds: 

1) Preamble (1 octet) 

2) Access Address (4 octets) 

3) Protocol Data Unit (PDU: conventionall}j^ 2- 
39 octets, but limited to 2-32 octets in nRF Enhanced 
ShockBurst’^” packet format) 

4) Cyclic Redundancy Check (CRC, 3octets) 

As per the core specifications of an advertisement packet, 
the 8 bit preamble and the 32 bit access address were set to 
10101010b and 0x8E89BED6 respectively. The preamble 
is used in the receiver to perform frequency synchronization, 
symbol timing estimation, and automatic gain control training. 
A 24 bit CRC is appended to the end of every packet, and 
is calculated over the PDU. It is important to note that 
some helds in the packet dehnition, marked as RFU, are 
reserved for future use; and are set to zero on transmission 
and ignored upon receipt. Depending on the PDU size, a BLE 
advertisement packet length could vary from 10 to 40 octets 
in the nRF Enhanced ShockBurst^*^ mode (as opposed to the 
standard 10 to 47 octets payload). The advertisement channel 
PDU has a Ihbit Header and a variable size Payload. 
Header: The Header consists of the following six helds 
spanning over 2 octets: 

1) PDU type (4bits) 

2) RFU (2 bits) 

3) TxAdd(lbit) 

4) RxAdd(lbit) 

5) Length (6bit) 

6) RFU (2 bit) 

The PDU type was set to ADV_NONCONN_IND (0010b) for 
transmitting non-connectable undirected advertising events. 
The following RFU, TxAdd and RxAdd helds were not used, 
and hence, were set to zero. The payload size is indicated 
by the Length held, and it can vary between 6 to 30 octets 
(instead of the standard 37 octets). 

Payload: The Payload for the ADV_NONCONN_IND PDU 
consists of the following two helds: 

1) AdvA (6 octets) 

2) AdvData (0-24 octets, instead of the standard 0- 
31 octets) 

The AdvA held holds the device address of the advertiser, 
which can either be public (if TxAdd = 0) or random (if 
TxAdd = 1). The AdvData held contains the advertisement 
data, and it consists of two logical parts: significant and 
non-significant. The significant part contains a 
sequence of AD structures. Each AD structure consists of the 
following two helds to populate a separate item of user data: 

1) Length (1 octet) 

2) Data (Length octets) 

• AD type (1 octet) 

* AD data (Length-1 octets) 

conventional/standard, we mean the guidelines provided in the Blue¬ 
tooth core specification v4. 
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The non-significant part extends the Advertising data 
to the remaining octets and contains all zeroes. For our 
implementation, we use the AD structures (defined in the core 
specification) presented in Table |I] 


TABLE I: Utilized AD Types 

Field 

Value 

Length 
AD type 
AD data 

2 octets 

Flags 

General Discoverable Mode 

Length 
AD type 
AD data 

6 octets 

Local Name (Shortened) 

Length 
AD type 
AD data 

4 octets 

Manufacturer Specific Data 
Timestamp, Transmit Time 

Delay (previous packet) 


The AD type Flags sets the discoverability preference 
of the device, and the General Discoverable Mode 
makes it detectable unconditionally. The Local Name 
(Shortened) AD type sets the short user-readable name 
of the device. The Manufacturer Specific Data AD 
Type is a generic, freely formattable data field, and includes 
the 24 bit timestamp value, and a 8 bit transmit time delay (of 
the previous packet). 

C. Timestamping®Transmitter 

On the nRF24C/!eep platform, an advertisement packet is 
transmitted by loading the TX FIFO and pulling the CE pin 
to a high state. One of the fields that is pushed into the SPI 
buffer is the current timestamp value. A second timestamp 
is also recorded once the TX_DS interrupt is seen by the 
microcontroller (i.e., when the radio’s IRQ pin is pulled 
down low), signaling the success of the transmit event. The 
difference between these two timestamps provides an accurate 
estimate of the time delays incurred due to send, access, and 
transmission; and this information is encapsulated into the next 
advertisement packet. As discussed in Section [Til-A[ due to the 
high determinism of send, access, and transmission time delays 
on the vRF2ACheep beacon platform, our implementation 
uses a single broadcast packet (instead of two) to reliably 
synchronize the transmitter and the receiver. 

The timestamping characteristics at the transmitter end is 
shown in Fig. and is depicted as a histogram showing 
the distribution of the transmitting time interval recorded for 
35000 broadcast packets. The distribution appears Gaussian 
with a best fit parameters of /i=0.201829/rs and a minuscule 
CT^=5.19537e — 07 ps. This latency characterization supports 
the determinism of our approach on the transmitter end. 

D. Timestamping®Receiver 

The receiver in our case is an Android v4.4.4 ported Google 
Nexus 5 smartphone. The complexity of the Android stack 
introduces several implementation challenges as the Bluetooth 


Distribution of Transmitter Time intervai 



Fig. 2; Transmitter side time stamping characteristics. 

Histogram showing the distribution of transmitter time interval 
recorded for 35000 broadcast packets, grouped into 1 ps 
buckets. The curve is a plot of the best-fit Gaussian parameters 
with p=0.201828 ps and tT^=5.19537e — 07 ps. 

packet must propagate through its several layers before it can 
be received by the application layer. However, for accurate 
timing information, it is important that time stamping is done 
as close to the hardware (layer) as possible. 

The reception time on the Android phone can be further 
divided into the following delivery delays: 

1) time taken by the Broadcom BCM radio to receive the 
message and raise an interrupt; 

2) time taken by the standard UART platform driver to 
hook into the BCM radio and register a RX event; and 

3) time taken by the Bluedroid stack to poll the UART 
driver, waiting to check if there are any bytes to be 
read (using the userial_read_thread () method 
in userial. c). 

Therefore, there is a significant, nondeterministic time lag 
between the instants when a RF message is actually received 
by the radio to when it is processed by the Bluedroid stack. 
Moving to software layers beyond the UART will limit porta¬ 
bility across different Android phones. Taking these facts into 
consideration, the lowest layer accessible entity on the Android 
Bluedroid stack is userial. cQ 

userial. c interfaces with the standard UART driver, and 
provides a common interface for the time-sync to work on 
multiple phones without introducing many hardware changes. 
However, timestamping at the level of userial. c introduces 
two complications. First, it is a generic container for catching 
all types of events (notification and other messages) sent out 
by the BCM radio to the underlying driver, and hence, there 
is a need to correctly identify the Bluetooth event. Second, 

^In the Android Bluedroid stack, userial.c is located at: 
/external/bluetooth/bluedroid/hci/src/ 
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Clock Drift Management: ts_counter = 100ms 



(a) Before correction: /r=2.62ms, (t^= 6.37312/rs, CDF(95%)=8.2ms; 
After correction: /r=0.0667ms, (T^=3.89512e-02/rs, CDF(95%)=0.64ms 


Clock Drift Management: ts_counter = 200us 



(b) Before con'ection: /r=2.3 ms, CDF(95%)=25 ms; After correction: 
fi=0.0605 ms, CDF(95%)=2 ms 


Fig. 3: Clock Drift Management. There is one order improvement in synchronization accuracy after compensating for clock 
drift, both in the average and 95% probability level. The accuracy and stability of the interval timer when set to 100 ms is 
significantly better than the case when it is configured to 200 fis. 


this problem can be overcome by waiting for userial.c 
to process the event list; but would introduce bnite, variable 
delays. Therefore, timestamps are recorded at the instant when 
an event is received at userial.c, but before any processing 
is performed on the list. 

The clock_gettime {CLOCK_REALTIME) method, 
which returns the real-time clock of the system in nanoseconds 
since the Epoch (00 : 00 1 January, 1970 UTC), is utilized 
to perform low-level timestamping on the receiver (phone) 
end. This representative value is passed on to the higher 
layer application, and the receive timestamp corresponding 
to the received BLE packet is subsequently determined. It 
is possible that a notihcation was received by userial.c 
from the radio, and the application layer was called following 
that particular notihcation being recorded as a timestamp. This 
introduces an error since the timestamp of the notihcation 
and not of the message is being used by the program. To 
overcome this problem, we adopt an algorithmic approach 
that determines the timestamp corresponding to a received 
packet. The algorithm; hrst, iteratively records the timestamps 
for the previous and the current packet; and then, subtracts 
each current packet’s timestamp value from every previous 
packet’s timestamp value. Upon completion, the value with 
the least deviation is taken as the best ht timestamp for the 
particular packet. 

E. Clock Drift Management 

Two clocks are considered synchronized when their relative 
deviation is bounded by some known value. However, as a 
result of clock drift arising from variations in clocking speed 
(frequency), two clocks will start to deviate even if they are 
set to identical values at initialization. 

In our case, the clock quality and speed on the transmitter 
and the receiver are vastly different. The nRE24C/!eep beacon 


unit has both high and low speed on-chip oscillators. The 
high speed oscillator operates at the frequencies of 64 MHz, 
48 MHz, 32 MHz, 16 MHz, 12 MHz, 8 MHz, 4 MHz, or 1 
MHz; while the low speed oscillator, which drives the timer, 
operates at 15 kHz. On the other hand, the Nexus 5 phone 
(control) unit is driven with a high precision clock pertaining 
to a few GHz. The offset between these two clocks will 
change over time due to frequency differences in the oscillator, 
which may be short-term arising from environmental factors 
(such as temperature variations, change in supply voltage, 
etc.,), or long-term due to aging effects. CheepSync, rather 
than modeling the frequency instability, does continuous skew 
adjustments over a measurement window on the phone unit 
as: k = {oi — b)/{tl — U); where, C is the average elapsed 
time at the reference clock and o is the average offset upto the 
sample point. This linear regression method offers a fast 
mechanism to hnd the frequency and phase errors over time. 

Fig.i shows the performance of time synchronization with 
and without clock drift compensation for different interval 
values, 100 ms and 200 /iS, over a period of 13 hours. With¬ 
out drift compensation, the mean error in synchronizing the 
transmitter and receiver clock is in the millisecond range, but 
can be bought down to a few microseconds with correction 
(that includes both low-level timestamping and clock drift 
management). Eor the specihc case of interval = 100 ms, the 
error before drift correction was; /i=2.62ms, <7^=6.37312 ps 
and 95% cumulative probability of 8.2 ms; while the respective 
estimates after correction were recorded as; /i=0.0667 ms, 
<T^=3.89512e-02ps and 0.64ms at the 95% cumulative prob¬ 
ability level (Eig. 3(a) i. Similar results were obtained for 
interval=200 ps, where there was one order of improvement 
in synchronization accuracy after compensating for clock drift, 
both in the average and 95% probability level (Eig. |3(b) i. 
The results also suggest that the accuracy and stability of the 
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interval timer when set to 100 ms is significantly better than 
the case when it is configured to 200 fj,s. The timestamp value 
when multiplied by ts_counter is more sensitive to changes 
in the interval timer because of its larger magnitude and error 
accumulation over time. The interval timer of 100 ms was, 
therefore, chosen as the preferred interval value due to its 
high stability, in addition to its lower energy cost. 


F. Multi-device Time Synchronization 

Considering the system dynamics, there are two forms of 
time synchronization across multiple devices. 

1) Many-Tx-to-One-Rx Synchronization: The scenario of 
synchronizing multiple Tx’s to a single Rx is a simple ex¬ 
tension to the case of deriving an estimate of time for a single 
(transmitter, receiver) pair; wherein the control unit becomes 
the reference point to perform synchronization. A reference 
point contains a pair of local and global timestamps where both 
of them refer to the same time instant. The control unit receives 
periodic broadcasts from beacon units within their coverage 
zone; else, their records are not entered. When the control 
unit collects the required measurement points, it estimates the 
skew and offset of the observed beacons and derives their 
coordinated time measure with respect to the global time. 

2) Many-Tx-to-Many-Rx Synchronization: The scenario of 
synchronizing multiple Tx’s to multiple Rx’s combines the 
above system infrastructure with a mechanism for different 
control units to share the skew and offset information of 
already visited beacon units. This could be achieved by a peer- 
to-peer interaction between the control units or through the 
Cloud infrastructure. For ease of implementation, we choose 
to take the later alternative with the Google Cloud platform. In 
this case, the absolute timestamp of the control unit along with 
the timestamp of the beacon unit is inserted into the Cloud. 
This data is then made accessible to other control units using 
the Google App Engine database. Whenever the timestamp of 
a new beacon unit is recorded by a control unit, a notification 
is sent to all other control units using Google cloud messaging. 
Once a control unit receives this message, it observes the 
last time it obtained the timestamp of the same beacon and 
computes the time difference. For instance, let the first control 
unit record timestamp from beacon i at time instance r^. 
Let the second control unit record another timestamp from 
the same beacon i with value tb at time instance ti,. Using 
these information, the offset (i.e., time difference) between 
the phones is measured as: (r^ — Tf, — (tb — to) * k). 

The relative time on the control units (that are Android 
phones) may vary from one to another by upto several seconds. 
It is, therefore, necessary to constantly synchronize with the 
nearest Network Time Protocol (NTP) server repeatedly in 
order to maintain very high precision for our time synchro¬ 
nization. For our implementation, we used an Android NTP 
applicatiorj^ and was configured to synchronize the control 
units at an interval of 30 seconds. 


^The Android NTP application is available at: 
https://play.google.com/store/apps/details?id=ru.org.amip.ClockSync&hl=en 


IV. Experimental Evaluation 
In this section, we evaluate the accuracy of CheepSync in a 
variety of controlled and uncontrolled experiments. The con¬ 
trolled experiments provide benchmark results for validating 
against uncontrolled experiments. 


A. CheepSync in Controlled Experiments 


Study- 1. The aim of this study was to obtain the baseline 
performance level of CheepSync for a many-tx-to-one-Rx syn¬ 
chronization scenario. It was, therefore, designed with a static 
setup of 8 beacon units and 1 control unit that was always 
covered by all the beacons. The beacons were configured to 
broadcast advertisement packets at an interval of 100 ms and at 
their lowest transmit power of —20dB. This experiment was 
conducted for about 13 hours wherein an average of 10000 
packets were received by the control unit from each beacon. 
Here, it should be noted that communication between the 
beacon and control units was over an interference channel as 
BEE does not provision for medium access control rules in 
the broadcast, advertisement mode. 

The experimentation results are shown in Eig. The 
system-level performance of CheepSync is depicted in 


Eig. 4(a) which shows an average error is 8 /iS and a 95% error 
probability of less than 0.04 ms. Eig. |4(b)[ disaggregates the 
combined (drift compensated) measurements into respective 
representations for each of the 8 beacons in the system. 
Here, it is evident that a large percentage of the beacon 
units show consistent behavior with an average error level of 
approximately 10 p,s and a worst case value of 0.04 ms; except 
beacon 7 that shows a 2 times better average performance but 
shoots over in the worse case performance level. 

Study-2. The aim of this study was to obtain the baseline 
performance level of CheepSync for the scenarios of one-tx- 
to-many-rx and many-tx-to-many-rx synchronization. For the 
prior scenario, the static setup consisted of a single beacon 
and 2 control units; while for the later scenario, the setup 
consisted of 8 static beacons and 2 static control units. The 
control units were always kept within the coverage range of 
the beacon(s); while all other beacon/control unit configuration 


parameters were kept consistent with study-1. Fig. 4(c) and 


Fig. 4(d) shows the cumulative time-sync error (i.e., the time 


difference between control units as explained in Section III-F21 


distributions for the prior and later setup respectively, and it is 
conditioned on contributing errors factors such as clock drift, 
NTP drift, etc.,. The result obtained from Fig. 4(c)| suggests 
that there is a 95% probability of the time synchronization 
error to be less than 5 ms with mean < 10/xs. A similar 


observation is also noted from Fig. 4(d) where the result 
suggests that there is a 90% probability of the time sync error 
to be less than 10 ps; although with the possibility of errors 
as large as 10 ms for 5% higher confidence levels. 


B. CheepSync in Uncontrolled Experiments 

Study-3. This experiment was designed to evaluate the per¬ 
formance of CheepSync in an uncontrolled setup, and hence, 
quantify its deviation from the respective benchmark results 
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Fig. 4: Performance of CheepSync. 
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obtained from study-1 and study-2. The experimentation space 
was in a [20x20] m portion of our office floor. In a real-world 
setting, we expect our office staff to be running CheepSync 
service on their smartphones as they walk through the various 
sections of this office space. They are also unlikely to be 
continuously walking as they would walk between locations 
of interest and spend more time at certain places. For our 
evaluation, we took the services of two people who were 
handed an Android smartphone running the CheepSync time 
service and they kept it with themselves for about an hour. 
The respective office space was instrumented with a set of 5 
beacon units in a manner that all beacons did not cover every 
end of the experiment zone. All other system configurations 
such as the beaconing rate and transmit power levels were kept 
the same as in study-1/2. 

For many-tx-to-one-rx scenario (Fig. 4(e)| i, a mean error 
of 12/rs was observed while its 95% error probability was 
less than 0.04 ms. As for the many-tx-to-many-rx scenario 
(Fig. 4(f) I, the 95% error probability was less than 22 ms 
with a mean error of 10 p,s. Both of these results are in good 


agreement with the baseline observations recorded in Fig. 4(a) 


and Fig. 4(c)[ thereby establishing the efficacy of CheepSync. 


V. Related Work 

Time synchronization has different perceptions. The first 
thought is to create a right chronology of events in a network 
by ordering. Lamport showed that the knowledge of the exact 
time instants is not required for achieving this weak notion 
of synchronization; and that a total order to events can be 
obtained by virtual clocks Q. The other perceptions are closer 
to the stronger sense of synchronization, and it is to derive a 
common time reference across distributed systems in a relative 
or absolute manner. 

While there exist many solutions in this space, they have 
some basic features in common: a messaging protocol to 
exchange time-stamped packets between nodes (some acting 
as client and others as time servers) in a network, techniques 
for overcoming nondeterministic delays, and an adjustment 
mechanism to update the local clock. However, they differ in 
aspects such as: whether the physical clocks of the network 
are kept consistent internally, or are synchronized to external 
standards; if the server is an arbiter of the client clock or is 
considered as a canonical clock, etc.,. 

For synchronization in WSNs, there exist multiple algo¬ 
rithms that use messaging passing as the basic mechanism to 
compensate for delays. The Reference Broadcast Synchroniza¬ 
tion (RBS) Q scheme, for example, uses packet broadcasts 
and exchange of time information among multiple receivers 
to eliminate transmission delays. By averaging over multiple 
transmissions, this method is able to achieve tight pairwise 
clock synchronization and reduces timing jitters associated 
with embedded devices. The Flooding Time Synchroniza¬ 
tion Protocol (FTSP) Q and Time-sync Protocol for Sensor 
Networks (TPSN) 0 use low-level hardware timestamping 
to eliminate similar time jitters. While both techniques use 
message broadcasts to form a spanning tree of all nodes in the 
network; FTSP (unlike TPSN) periodically adjusts the local 


TABLE II: Accuracy Measure of Time Synchronization 
Algorithms 


Time Sync. Protocol 

Avg. Accuracy (/js) 
(Single Hop) 

RBS 1^ 

29.10 

TPSNTm 

16.90 

FTSP 1^ 

01.48 

GIossvTj] 

0.50 

Rowe et al. |l0[ 

1000.00 

CheepSync 

10.00 


clock rate to compensate for drift and also handles dynamic 
topology changes. Using flooding as the basic communication 
primitive (like FTSP), Glossy Q uses a novel architecture that 
uses constructive interference to its advantage and implicitly 
synchronizes nodes as the flooding packet propagates through 
the network. Compared to its processors. Glossy delivers 
higher accuracy by flooding packets within a few milliseconds 
using the approach of Virtual High-resolution Time (VHT). 
Rowe et al. ng introduced hardware assisted clock synchro¬ 
nization in WSNs. Here the key idea was to tune into the 
magnetic field radiating from existing AC power lines, and 
thus leverage a highly available common clock source for 
synchronization. 

CheepSync explores a form of synchronization that differs 
from traditional WSNs. Its fundamental design philosophy 
is to provision for synchronization between transmitters and 
receivers, as opposed to traditional WSN protocols that syn¬ 
chronize a set of receivers with one another. Performing 
receiver-receiver synchronization removes uncertainties asso¬ 
ciated with send and access delays, the biggest contributors to 
non-determinism in latency, from the critical time path. System 
level complexities are further reduced by using symmetric 
WSN platforms that run on simple OS. All of these factor con¬ 
glomerates towards higher levels of synchronization accuracy 
that is typically evident in traditional WSNs. CheepSync, in 
contrast, operates on highly asymmetric devices with vast dif¬ 
ferences in system complexity. Its synchronization methodol¬ 
ogy, system architecture, and wireless communication standard 
utilized for delivering the respective solutions are completely 
different. CheepSync achieves a high synchronization accuracy 
that is better than the time-sync levels of RBS, TPSN and 
Rowe et al.; but is less precise compared to FTSP or Glossy 
(Table |II]). 


VI. Conclusion 

CheepSync is a time synchronization service for BLE adver¬ 
tisers; and therefore, is a key enabler for a variety of loTH ap¬ 
plications where mobile crowdsourcing, using existing infras¬ 
tructure and ubiquitously used platforms along with ‘humans’ 
as the data mule, has emerged as an alternate architecture. 
These applications typically require different levels of time 
accuracy. Eor instance, a few milliseconds may be sufficient 
to disambiguate the handwash event of medical practitioners 
in a hospital setting, but a significantly higher accuracy level 
of a few microseconds would be required to secure the same 
system against possible gaming. By empirical evaluations. 
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we showed that CheepSync is capable of gracefully handling 
timing requirements as low as 10 /is.lt is build on the existing 
Bluetooth v4.0 standard, and hence is, generic to all devices 
using the low energy profile of Bluetooth. 
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